ftp.cs.arizona.edu/ftp.cs.arizona.edu.tar/ftp.cs.arizona.edu/icon/newsgrp/group97a.txt/000078_icon-group-sender _Sun Mar 9 16:01:56 1997.msg

Internet Message Format | 2000-09-20 | 4KB

Received: by cheltenham.cs.arizona.edu; Mon, 10 Mar 1997 12:47:12 MST
Date: Sun, 9 Mar 1997 16:01:56 -0600 (CST)
From: "Chris D. Tenaglia" <[e-mail]>
To: Alan Watson <[e-mail]>
Cc: [e-mail]
Subject: Re: More General Events In Icon
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Errors-To: [e-mail]
Status: RO
Content-Length: 3321

>
> I'm new to Icon. I came to it as something to add to the two tools I
> have for solving problems: C on one hand and contortions with awk,
> sed, m4, and other shell tools on the other. Until recently I was
> singularly impressed and very optimistic, but I've come across what
> appears to be a fundamental problem and it's making me think again.
> I'd be very grateful if someone more experienced with Icon than I
> could comment on this.
Icon as a general shell and file tool is great. It's also well
designed for trying out different algorythms and approaches to
problems. But It's a high level language, so I wouldn't use it
for things that require real time low level device control.

>
>                         --------
>
> A number of applications require responses to events. These events are
> commonly: a mouse or keyboard action in a window (graphics events);
> the passage of a certain amount of time (alarm events); and the
> presense of data ready to be read from a file (input events).
>
...snip
The clock.
Maybe using more explicit file handles and keeping everything
in a tight polling loop?

>
> (b) An application I use on a regular basis for image processing
> combines a command line interface with a graphics browser. The requires
> responding to both graphics events and input events. (Re-writing xterm
> within the application would not be acceptable!)
I wrote something like this back in '88. I used a Decwindows microvax I
running vms 4, and it had both vt100 and tek4014 emulation. If I would
telnet in a tek window to a supercomputer. I slapped together an icon
graphics enviroment that was interactive. No mouse control, but on a
19" screen the icon code took up 2-4" and would compile, run and display.
I could direct the output to a file and run tek2ps to make it printable.
Primitive by todays measure, but pretty cool back then.

>
> (c) A guy down the corridor is implementing the user interface to a
> telescope control system. The telescope is controlled by a networked
> PC. The user interface runs on a (remote) UNIX work station. The user
> interface and the PC communicate by writing and reading NFS files. The
> user interface also has a command line interface and a graphical
> display. The program must respond to all three kinds of events: it
> handles graphical and input events as expected, but in addition must
> check for a NFS file every half second or so.
This is a real time hardware control problem. Using a shared file
for a protocol is ok if the systems are fast enough. I can understand
telescopes getting computers in them as a natural evolution. One would
almost prefer a telescope be dumber like a plotter. It could almost
run HPGL off a serial or HPIB interface. Then you could print to it.
RA6h42.9m
DEC-16d39'
FOCUS
FILTERR100G100B78
etc,...


>
>                         --------
>
> Throwing everything into a language is probably not a good idea.
> Therefore, we should not expect one language to be able to do
> everything. However, the unsuitability of Icon to these three
> applications astonished me; they seemed at first glance well within
> the domain of problems it is intended to solve.
>
> Am I missing something?
>
> Alan
>
But I wouldn't use it to write an OS kernal , file system, or
re-invent someone elses wheel IMHO.

Chris.